COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	This is a description of the many changes that have been added to
C00014 ENDMK
C⊗;
This is a description of the many changes that have been added to
Stanford monitor 8.69V having to do with privileges and file access

See the UUO manual section on privileges for a description of the meaning
of the three letter privilege names.

The following privileges have been flushed: TLK KIL UDP SEG FBW and PRI.
They are not needed because of other changes to the monitor.
Anyone may enter a talk loop except if the recipient has done TTY GAG.
Anyone may kill a job, but you must specify the PPN of the job to be
killed if it isn't one of yours and the victim and the CTY are notified.
Nobody may override segment protection now and anybody may override UDP
password and last track protection in old-style access.  (I.e. anyone can
write on an old-style pack; nobody can reformat a new-style pack into an
old-style one.)

Everybody's privileges have been flushed.  All 1, areas have been given
the MAS privilege (see below).  Certain users have had their privileges
restored.  Say R PRIV to see what privileges you have.

The concept of user groups has been defined.  There are 5 groups currently
defined: the "master account" group (MAS), the "systems programmer" group
(SYS), the "DEC proprietary software" group (DEC), the "secretary" group
(SCY) and the "accounting" group (ACT).  Corresponding to each group is
a privilege bit (the three character name in parentheses).  A user (that is,
a PPN) is defined to be "in" a group, if that PPN has the corresponding
privilege.  A user may be in more than one group.

Each UFD (again, PPN) also has associated with it a set of "group access" bits.
These bits correspond to the "group privilege" bits.  A group access bit (say
the SCY group access bit) is turned on in a UFD if the owner of that UFD
wishes any member of the corresponding group (i.e., any secretary) to be
able to access files in that UFD as if they owned them.  So the group
access scheme in effect is used to OVERRIDE non-owner protection.
Whenever there is a match between an accessor's group privilege bit and
a UFD's group access bit, the accessor is given OWNER access to the UFD.

There is one exception to the above, namely the MAS privilege.  The MAS
privilege will give owner access to a UFD with the MAS group access bit
only for the same PROGRAMMER.  That is, the MAS privilege is local to
a given user.

So, the way "master accounts" are implemented, for example, is that all
of a user's UFDs have the MAS group access bit turned on and the user's
1, account has the MAS privilege.  This lets the user protect all his areas
against everyone but himself, while letting him access all his areas while
logged in under his project "1".

A user may alter the group access bits of his area by logging in on that
area with % (as if he wanted to change his password or protections).
LOGIN will ask which group access bits he wishes to have.

Initially, ALL 1, accounts have been given the MAS privilege.  All areas start
out with NO group access bits turned on (that includes MAS).  When LOGIN
is asked to create a new 1, account, it will automatically give it the
MAS privilege.  If some user wishes to have some other project be the master
project, that user should ask a systems programmer for assistance.

LOGIN will not give you most privileges (including MAS) unless you log
in with a password.  If you have a remote only password, you can log
in with ! which will force LOGIN to ask for a password (and then it will
give you your due privileges).

For most users, none of this makes any difference because they don't protect
any of their areas or files.  If a user has several areas, but none of them
are protected, then that user doesn't need any privileges (MAS or anything else)
to access that area.  The group access scheme is a way of "DEPROTECTING" an
area rather than increasing its protection.

A user that wishes to be able to have access to a protected area that he owns
without actually loggin in on that area should log in on that area with % and
set the MAS group access bit for that area.  Then the user can log in on his
area that has the MAS privilege ,i.e., his master account area (which will be
his 1, area unless he doesn't have one or has requested (to a system programmer)
that it be changed to some other project) and get owner access to the protected
area.  However, the user will have to use a password to get the MAS privilege
when he logs in on his MAS area.

There is a new monitor command called UNPROT, which takes a filename as
an argument and changes that file's protection to 005 if it can.
This should obviate the need for many users to have privileges to get around
file protection.  UNPROT keeps a log of all protection changes and also
reports them on the CTY.  UNPROT does not affect UFD protections so you
can be absolutely safe against intrusion by protecting your UFD (log in
with %) at the cost of not having UNPROT available for you.  But on the
other hand, you (or anyone with owner access) can always change the
protection of your files (and your UFD) in other ways; UNPROT is primarily
intended for people who write a file somewhere else, e.g. a system area,
and then find it protected against them.  UNPROT's log is called
UNPROT.LOG[1,2] and anyone may read it but nobody can write it (except
implicitly by using the UNPROT command).  You can't UNPROT
UNPROT.LOG[1,2].

There are two kinds of privileges: passive and active.  All active privileges
are temporary, meaning they tend to go away when you do anything like
deposit or run a program.  The DDT command no longer clears temporary privileges.
The passive privileges are the ones you are entitled to.  Certain
privileges are checked from the active and others from the passive word.
Those tested from passive (ATT, DEV, LUP, LIV and the group privileges) are
the ones that must not be temporary privileges.

The ENABLE command cannot be used on most privileges.  It can only be used
for UPG, LUP and LIV and works in the following ways.  Anyone can say
ENABLE UPG and they will get UPG turned on in their active privileges.
The idea here is that they will then say FLUSH TTYn.  FLUSH will not work
on a terminal that has a job logged in unless you have UPG in your active
privileges, and FLUSH will turn off UPG after the flush (anyone can FLUSH
a terminal that is not in use).  Anyone can say ENABLE LIV to set the LIV
privilege in the passive word.  Finally, anyone can say ENABLE LUP to set
LUP in the passive word, but it will only work for users who are local.
The DISABLE command can disable any of these three privileges.

The SETPRV UUO is used to set a job's active privileges.  It will allow
any passive privilege to be made active.  It always allows UPG to be
made active, so anyone may run SYSDWN (which does a SETPRV to get UPG).
It returns the job's active privileges except for LUP which it returns
from the passive privileges.  Funtion 2 of the GETPRV UUO has been flushed.

In systems after and including 8.69W there is a new command called UNDEL.
The syntax is UNDEL NEW_FILE←DELETED_FILE.  It undeletes DELETED_FILE
and writes it into NEW_FILE.  NEW_FILE and the ← may be omitted and it
will write it back as DELETED_FILE.  The new file is actually written
from scratch, so some of the information about the old file is lost, like
who last wrote it, with what program and when.